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Remarks 

This is in response to the final Office Action mailed on April 8, 2005. Claims 1, 13, and 
18 are amended, support for the amendments being found, for example, at page 15, line 10 through 
page 16, line 3 of the present application. Claims 1-27 remain pending. Reconsideration and 
allowance of all claims are respectfully requested in view of the following remarks. 

L Claim Rejections - 35 U.S.C S 103 

In the Office Action at paragraph 4, claims 1-27 stand rqected under 35 U.S.C. § 103(a) as 
being unpatentable over Goodwin etal. (US 6,1 58,049) in view of Le vine etaL (US 6,349,406) and 
further in view ofRoediger et al (US 5,960,198). This rejection is respectfully traversed, and the 
correctness of the rejection is not conceded. Reconsideration is requested for at least the following 
reasons. 

A. Claims 1-12 

Claim 1 recites, among other limitations, a performance code marker module for obtaining 
and storing the run-time internal state data for later retrieval at predefined points corresponding 
to permanently inserted performance markers, wherein the application program calls the 
perfbimance code marker module each time one of the permanently inserted performance 
markers is reached. 

As noted in previous responses, permanently inserted performance markers are intended 
to be in the final version of an application program that is ultimately delivered to end users. The 
permanently inserted performance markers impose little, if any, overhead to operate and thus are 
not removed from the application program when testing of the application is completed. 

In addition, the application program is configured to call performance code marker 
module each time one of the permanently inserted performance markers is reached. If run-time 
internal state data is not being collected, the performance code marker module simply returns to 
the calling application program. Application, p. 15, 1. 10 - p. 16, 1. 3. In this manner, permanently 
inserted performance markers allow performance testing on a version of the application program 
that is identical to the version that is ultimately considered the delivered product, thereby enhancing 
the reliability of such testing. 
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The rejection concedes that Goodwin fails to disclose permanently inserted performance 
markers, as recited by claim 1. Levine likewise fails to disclose or suggest permanently inserted 
performance markers. 

The rejection cites column 8, lines 15-37 of Roediger as disclosing insertion of 
instrumentation into code along with a profiling bit that can be enabled or disabled, allowing the 
instrumentation to be present in the code even when profiling is not desired. The rejection further 
states that it would have been obvious to include permanently inserted performance markers as per 
the teachings of Roediger . This characterization of Roedieer is respectfully traversed, and 
reconsideration is respectfully requested for at least the following reasons. 

i. Roediger does not suggest permanently inserted performance markers 
It is respectfully suggested that Roediger fails to disclose or suggest permanently inserted 
performance markers. Roediger identifies three phases for its profiling system: (1) an 
instrumentation phase where a program is retrofitted with "mfbnnation collecting" instructions; (2) 
a benchmarking phase where the program is run and profile information is collected; and (3) an 
optimization phase where the program is recompiled and modified in light of t he profile 
information. Roediger. col 4, 11. 25-31. Roediger therefore differentiates between the 
instrumentation and benchmarking phases, and the optimization phase, where the program is 
optimized to form the delivered product Roediger teaches away from the inclusion of instrumented 
code in the delivered product and therefore does not suggest permanently inserted performance 
markers. 

Roediger further states: "Instrumented computer program 28 will be executed on a set of 
inputs believed to represent a typical runtime environment." Roediger, col. 8, 11. 30-32. Therefore, 
Roediger only discloses instrumented code that is used in a simulated environment with a set of 
inputs "believed to represent a typical runtime environment" See also Roediger. col. 6, U. 43-47 
(noting that the instrumented code is executed using simulated inputs), jtoediger consequently fails 
to disclose or suggest that the instrumented program includes permanently inserted performance 
markers. 
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il Roediger docs not suggest calling a performance code marker module each 
time a permanently inserted performance marker is reached 

Roediger discloses using a dedicated bit that is checked by the instrumented program prior 
to the execution of any instrumented code. If the bit is enabled, the instrumented code is executed. 
If the bit is not enabled, the instrumented code is skipped Roediger. coL 6, 11. 21-32. The system 
disclosed by Roediger therefore suffers from the same problem as other systems in that, when 
profiling is disabled, sections of instrumented code are skipped The skipping of instrumented code 
by the program creates performance differences between the program with instrumentation enabled 
and the program with instrumentation disabled, thereby resulting in unreliable testing. See 
Application, p. 2, 1. 3 - p. 3 7 1. 2, 

In sharp contrast, claim 1 recites that the application program calls the performance code 
marker module each time one of the permanently inserted performance markers is reached In this 
manner, the application program performs in a similar manner whether or not run-state data is 
collected, thereby enhancing the reliability of performance testing. 

Reconsideration and allowance of claim 1, as well as claims 2-12 that depend therefrom, are 
respectfully requested for at least these reasons. 

B. Claims 13-27 

Claims 13 and 18 both recite determining if run-time internal state data is to be collected 
at each code marker by calling a performance code marker module. Therefore, claims 13 and 18, 
as well as claims 14-17 and 19-27 that depend respectively therefrom, should be allowable for at 
least reasons similar to those provided above with respect to claim 1. Reconsideration and 
allowance are respectfully requested 

II. Conclusion 

The rem arks set forth above provide certain arguments in support of the patentability of 
the pending claims. There may be other reasons that the pending claims are patentably distinct 
over the cited references, and the right to raise any such other reasons or arguments in the future 
is expressly reserved. 
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For all of the above reasons, the pending claims are patentable over the prior art of 
record- Favorable reconsideration in the form of a Notice of Allowance is requested. Please 
contact the undersigned attorney with any questions regarding this application. 



Respectfully submitted, 

MERCHANT & GOULD P.C 
P.O. Box 2903 

Minneapolis, Minnesota 55402-0903 
(612)332-5300 



Date: June Z?\ 2005 



Name: Robert A. Kalinsky ( 

Reg. No.: 50,471 

RAK 
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